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Sir: 



APPEAL BRIEF 



Applicant respectfully appeals from the final rejection mailed November 6, 2003. 
I. REAL PARTY IN INTEREST 

The real party in interest is Nortel Networks Limited, the assignee of the present 
application by virtue of the assignments recorded at Reel/Frame 010516/0430 and 010445/0305. 



II. 



RELATED APPEALS AND INTERFERENCES 



None. 



III. STATUS OF THE CLAIMS 



Claims 1-8, 19-24, 27-30, and 32-42 have been finally rejected and are the subject of this 



appeal. 
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IV. STATUS OF AMENDMENTS 

No amendments of the claims were submitted after final rejection. 

V. SUMMARY OF THE INVENTION 

According to an aspect of the invention, real-time, text-based messaging can be 

established between first and second terminals through servers in first and second communities, 
which are associated with different service providers. As recited in claim 1, a first server in the 
first community receives a request to establish the text-based messaging session, while a second 
server in the second community processes the request to establish the real-time, text-based 
messaging session. According to claim 19, a server in the first community receives a request 
from an entity in another community to establish a text-based messaging session. According to 
claim 20, a system in the first community receives a request from a subscriber in a second 
community, and the system establishes a text-based messaging session between the subscribers 
of the different communities. 

As shown in Fig. 1 of the specification, according to an embodiment, a communications 
system 10 includes a plurality of communities, with a first community 14 and a second 
community 16 shown. The communities 14 and 16 are serviced by service providers 20 and 22, 
respectively, and are coupled by a network 8. A "network" may refer to one or more 
communications networks, links, channels, or paths. Specification p. 3, 11. 29-33. 

A "community" refers to a group of terminals or users that are served by a service 
provider. A service provider controls access to certain networks for terminals and users in the 
served community. The service provider also may determine the types of services that a user or 
terminal has subscribed to. A service provider includes one or more server systems that 
terminals (desktop and mobile units) may be linked to. A subscriber, through a terminal, may be 
logged on to a server system to establish a link to the server system. When the subscriber is 




logged on a server system of the service provider, he or she has an established link with the 
service provider over which communications between the server system and terminal may occur. 
When the subscriber is not logged on, the communications link is not active. Logging on to a 
server refers to providing some type of an identifier, usually in the form of a user name and 
password, to identify a user or terminal with the server so that a session can be started on the 
server. Thus, for example, logging on to a server of an Internet service provider allows a 
subscriber access the Internet. Specification p. 4, 11. 1-15. 

In accordance with some embodiments, "real-time" inter-community text-based 
messaging or communications may be performed between terminals in different communities, 
such as communities 14 and 16 served by service providers 20 and 22, respectively. As used 
here, "real-time" messaging communications refer to. messaging or communications in which 
some interaction (in the form of exchange of text or other types of viewable messages) is 
occurring between at least two end users who have acknowledged each other's participation in 
the session. This is distinguished from traditional electronic mail messaging, in which an 
interactive session is not established between users. A "text-based" messaging or 
communications session is one in which users or terminals exchange text or other forms of visual 
data to communicate. Specification p. 4, 1. 27-p. 5, 1. 3. 

To provide the ability to establish text-based chat or messaging sessions across different 
communities, several architectural solutions are provided. For example, in a first architecture (a 
distributed architecture), chat applications may be available on servers of all service providers. 
A chat application refers to a set of spftware and hardware components that enable a user to 
participate in a text-based chat or messaging session. Specification p. 12, 11. 1-7. 
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A second, alternative architecture includes chat applications residing on computers or 
other terminals of all users involved in the chat or messaging session. Another architecture 
includes chat applications residing on servers of all involved service providers combined with a 
third party server that mixes the inter-service provider chat or messaging sessions. Another 
architecture includes chat applications residing on the servers of either the origination or 
termination service provider (but not both). The servers referred to may be part of the contact 
servers described in connection with Fig. 1. Specification p. 12, 11. 8-15. 

Fig. 5 of the specification shows a distributed architecture for establishing chat sessions 
between multiple users (users A, B, and C illustrated) that includes chat applications provided in 
each of servers 400, 402, and 404, respectively, of service providers associated with users A, B, 
and C, respectively. Specification p. 12, 11. 16-19. . 

Another type of architecture includes chat client applications residing on the terminals of 
involved users instead of on the service provider servers 400, 402, and 404. Each chat client 
creates an object associated with an initiated chat session, similar to chat objects created by the 
servers in the embodiment of Fig. 5. Each client chat object checks the incoming chat data to see 
whether it is addressed to it and decodes the message and presents it to the chat client user 
interface. Specification p. 14,11.30-33. 

Fig. 7 of the specification shows a centralized architecture in which a third party or 
central server 602 cooperates with servers associated with the several service providers A, B, and 
C to establish a chat session between inter-community terminals. An advantage of using the 
centralized architecture is that complexity of inter-domain chat systems is reduced, as compared 
to the Fig. 5 architecture. Specification p. 15, 11. 10-14.7 
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Although several embodiments have been described above, other embodiments are also 
covered by the claims on appeal. 

VI. ISSUES 

A. Are Claims 1-4, 8, 19-24, 27, 28, 30, 33, 35, 37, 39, and 41 Obvious Over The 
Asserted Combination of DeSimone And Auerbach, and Is Claim 32 Obvious Over 
The Asserted Combination of DeSimone, Auerbach, and Busey? 

B. Are Claims 5 And 6 Obvious Over The Asserted Combination Of DeSimone, 
Auerbach, And Ogle? 

C Are Claims 7 And 29 Obvious Over The Asserted Combination Of DeSimone, 
Auerbach, And Ishikawa? 

D. Are Claims 34, 36, 38, 40, And 42 Obvious Over The Asserted Combination Of 
DeSimone, Auerbach, And Busey? 



VII. GROUPING OF THE CLAIMS 



Group 1: 


1-4, 8, 20-24, 27, 30, 32, 33, 37, 39, 41 


Group 2: 


19, 28, 35 


Group 3: 


5,6 


Group 4: 


7,29 ' 


Group 5: 


34, 36, 38, 40, 42 



Within each group, the claims stand and fall together. 
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VIII. ARGUMENT 

All claims should be allowed over the cited references for the reasons set forth below. 

A. Are Claims 1-4, 8, 19-24, 27, 28, 30, 33, 35, 37, 39, and 41 Obvious Over The 
Asserted Combination of DeSimone And Auerbach, and Is Claim 32 Obvious Over 
The Asserted Combination of DeSimone, Auerbach, and Busey? 

Independent claim 1 was rejected as being obvious over DeSimone and Auerbach. With 
respect to independent claim 1, the Examiner conceded that DeSimone does not teach a first 
community associated with a first server provider and a second community associated with a 
second, different service provider. 1 1/6/2003 Office Action at 2. Claim 1 recites that a server in 
a first community associated with a first service provider receives a request, and that the server 
in a second community associated with a second, different service provider processes the request 
- - - to establish a real-time, text-based messaging session between first and second terminals through 
the first and second community servers. If DeSimone does not teach first and second 
communities associated with respective first and second service providers, as conceded by the 
Examiner, then DeSimone fails to teach the combination of the receiving and processing acts of 
claim 1. In fact, DeSimone teaches a single service provider system — DeSimone describes a 
chat room system in which users must log on to a chat server (regardless of whether the user 
joins a chat room or not) to permit text chat sessions to be established with one another. 
DeSimone, 1:48-2:1 1, 5:51-54. In DeSimone, only one service provider is contemplated. See 
DeSimone, 1 :51-54 ("Any user may elect to join a chat room (become a participant), subject to 
prior subscription or registration procedures imposed by the on-line service provider or operator 
of the chat server(s).") (emphasis added). 

To address the deficiency of DeSimone, the Examiner cited Auerbach as disclosing the 
elements missing from DeSimone. Although Auerbach refers to servers of multiple service 
providers (106, 108, 110, in Fig. 2 of Auerbach), there is no teaching or suggestion whatsoever 
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in Auerbach of receiving a request indicating desired real-time, text-based messaging from a 
server in a first community associated with a first service provider, and processing the request by 
the server in the second community associated with the second, different service provider. 
Figure 2 of Auerbach shows a system 100 in which a client application is able to communicate 
with servers of multiple service providers through a conversion platform 112. Auerbach, 4:51- 
58. The operation of the system 100 of Figure 2 is described at column 7, starting at line 65 
through column 8, at line 38, in conjunction with Figures 2 and 3. 

The user at the client 102 can communicate text messages with another endpoint that is 
connected to any one of the servers 106, 108, and 1 10. Thus, if the destination endpoint is 
connected to the first server 106, outgoing text messages are converted by an SP1 protocol 
services module 130 (Figure 3 of Auerbach) to a first format for the first service provider SP1 . 
Auerbach 8:9-12. If the destination endpoint is connected to the second server 108, then an SP2 
protocol services module 132 (Figure 3 of Auerbach) converts the text messages to the second 
format of the second service provider SP2. Auerbach, 8:27-34. Messages received from either 
the SP1 server 106 or SP2 server 108 undergo the reverse process. Auerbach, 8:19-20. Note, 
however, that although multiple service providers are disclosed by Auerbach, one server 
associated with a first service provider does not receive a request for real-time, text-based 
messaging, while another server associated with a second service provider processes the request 
to establish the text-based messaging session. In Auerbach, the client system 100 establishes 
instant messaging sessions with one or more of the servers associated with different service 
providers. In other words, the intelligence to establish such instant messaging sessions 
(including translation between different formats for different service providers) resides in the 
client system 100. As a result, the separation of tasks recited in claim 1, where a server in a first 
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community (associated with a first service provider) receives a request, while a server in a 
second community (associated with a second service provider) processes the request, is not 
performed in Auerbach. 

Therefore, even if DeSimone and Auerbach can be properly combined, the hypothetical 
combination of the references fails to disclose or suggest each and every element of claim 1 . A 
prima facie case of obviousness has thus not been established with respect to claim 1 for at least 
this reason. See MPEP § 2143 (8 th ed., Rev. 1) at 2100-125. 

There also is no motivation to combine the teachings of DeSimone and Auerbach, as 
there is no need within the DeSimone system of performing real-time, text-based messaging 
sessions between terminals associated with different community servers. DeSimone teaches only 
one service provider; Therefore, DeSimone would-have no need for the common conversion 
platform 1 12 of Auerbach, as DeSimone does not have the incompatibility issues discussed in 
Auerbach. In fact, the teachings of DeSimone would lead a person of ordinary skill in the art 
away from the claimed invention and from the combination with Auerbach as proposed by the 
Examiner. DeSimone teaches that participants of its chat room must adhere to prior subscription 
or registration procedures imposed by the on-line service provider or operator. DeSimone, 1:51- 
54. There is no indication whatsoever in DeSimone that it would even be desirable to 
incorporate multiple service providers, with their respective procedures, into the chat room 
techniques described by DeSimone. 

The teachings of the references must be considered in their respective contexts to 
determine whether each reference actually teaches or suggests elements of the claim. The 
teachings of the references cannot be ignored in an attempt to perform a piecemeal combination 
of isolated elements, as the Examiner has done. Applicant's arguments are focused on the actual 
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teachings of the references applied in the obviousness rejection. These arguments clearly rebut 
the piecemeal selection and arbitrary combination of elements, taken wholly out of the context of 
the teachings of the respective references, in the obviousness rejection asserted in the Office 
Action. A person of ordinary skill in the art would not pick and choose elements in isolation to 
combine such elements from multiple references — instead, such a person of ordinary skill would 
understand the teachings of each reference in their entirety. 

Because there is no motivation or suggestion to combine DeSimone and Auerbach, a 
further requirement of a prima facie case of obviousness has not been established. See MPEP § 
2143 at 2100-124 to 125. 

With respect to independent claim 19, the hypothetical combination of DeSimone and 
Auerbach does not teach or suggest the recited interface unit and controller. The interface unit of 
claim 19 (which is in a server associated with a first community) is adapted to receive a contact 
request over the network from an entity associated with another community, with the entity not 
being logged onto the server associated with the first community. Note that the communities are 
associated with different service providers, as recited in claim 19. The hypothetical combination 
of DeSimone and Auerbach does not teach or suggest these elements. 

Therefore, a prima facie case of obviousness has not been established with respect to 
claim 19 for at least this reason. Also, the obviousness rejection is defective because no 
motivation or suggestion exists to combine DeSimone and Auerbach, as discussed above. 

Similarly, independent claim 20 recites instructions that when executed cause a system in 
a first community associated with a first service provider to receive a request from a subscriber 
in a second community associated with a second service provider, and to perform various other 
acts in response to the request. The processing of a request for a desired text-based messaging 
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session by a system in one community (associated with one service provider) of a request 
received from another community (associated with another service provider) is not taught or 
suggested by the asserted combination of DeSimone and Auerbach. 

Claim 32 depends from claim 1, and is thus allowable for at least the same reasons as for 
claim 1. Because the rejection of claim 1 over DeSimone and Auerbach is defective, it is 
respectfully submitted that the rejection of dependent claim 32 over DeSimone, Auerbach, and 
Busey is also defective. 

For the foregoing reasons, it is respectfully requested that the final rejection of claims 1- 
4, 8, 20-24, 27, 30, 32, 33, 37, 39, and 41 be reversed. 

B. Are Claims 5 And 6 Obvious Over The-Asserted .Combination Of peSimone, 
Auerbach, And Ogle? 

Claim 5 depends indirectly from claim 1, and thus is allowable for at least the same 
reasons as for claim 1 . 

Claim 5 was rejected over the asserted combination of DeSimone, Auerbach, and Ogle. 
In view of the improper application of the asserted combination of DeSimone and Auerbach 
against base claim 1, it is respectfully submitted that the asserted combination of DeSimone, 
Auerbach, and Ogle also does not render claim 5 obvious. Moreover, there is no motivation or 
suggestion to combine DeSimone, Auerbach, and Ogle to achieve the claimed invention. 

Claim 5 recites "sending a message to a predetermined communications deice other than 
the second terminal if the second terminal does not have an established connection with the 
second community's server." The teachings of DeSimone are inconsistent with the teachings of 
Ogle (the teachings of DeSimone are also inconsistent with the teachings of claim 5). In 
DeSimone, the system for enabling chat sessions between users of a chat room require that the 
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names of participants be visible to each other. DeSimone, 5:22-34, 51-54. In chat rooms, users 
announce their availability to receive messages. DeSimone, 2:8-9. When a user logs onto a 
server, a notice may be sent to others (such as those on a buddy list). DeSimone, 2:5-8. 

Thus, the chat system of DeSimone requires that users be logged on to a server so that 
users can be visible to each other through chat software. This is inconsistent with the subject 
matter of claim 5. The teaching in DeSimone that requires users be logged on to a server so that 
users can be visible to each other is also inconsistent with the teachings of Ogle regarding 
alternative actions taken by an instant messaging system (IMS) in response to detecting that a 
user is not logged on to the IMS. Ogle proposes that users may register one or more alternative 
message delivery mechanisms (such as pagers, cell phones, etc.) through which they are 
available" as an" alternative to an instant messaging- system. In contrast, _DeSimone teaches a 
solution (which requires that users be logged on) that is at odds with the system described in 
DeSimone. "A reference may be said to teach away when a person of ordinary skill, upon 
reading the reference, would be discouraged from following the path set out in the reference, or 
would be led in a direction divergent form the path that was taken by the Applicant." In re 
Gurley, 27 F.3d 551, 553, 31 U.S.P.Q. 2d 1 130 (Fed. Cir. 1994). Here, a person of ordinary skill 
in the art looking to the teachings of DeSimone would have been discouraged from employing 
the system of Ogle, since DeSimone requires that users be logged on so that they be visible to 
each other for initiating chat sessions. 

In view of the foregoing, it is respectfully submitted that claim 5 is not obvious over the 
asserted combination of DeSimone, Auerbach, and Ogle. Therefore, it is respectfully submitted 
that the final rejection of claims 5 and 6 be reversed. 
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C. Are Claims 7 And 29 Obvious Over The Asserted Combination Of DeSimone, 
Auerbach, And Ishikawa? 

Claim 7, which indirectly depend from claim 1, is allowable for at least the same reasons 
as for claim 1. Claim 7 was rejected as being obvious over the asserted combination of 
DeSimone, Auerbach, and Ishikawa. 

Claim 7 recites the following additional subject matter: "performing a reverse log on to 
the second terminal if the second terminal does not have an established link with the second 
community server. 1 ' Again, as previously discussed, DeSimone teaches that users must be 
logged on to enable the users to be visible to each other for establishing chat sessions. This 
teaching is at odds with the subject matter of claim 7, as well as with the teachings of Ishikawa. 

Ishikawa teaches a solution for contacting a user in case a user does not have an IP 
connection. Ishikawa, Abstract. If an IP connection is not even established, as discussed in 
Ishikawa, then a user of a client that does not have the IP connection would not be visible to 
other users in the DeSimone chat system. Thus, the teachings of Ishikawa and DeSimone are 
inconsistent, and as a result, there is no motivation or suggestion to combine DeSimone, 
Auerbach, and Ishikawa. Therefore, claim 7 is not obvious over the asserted combination of 
references. 

Claim 29 depends from claim 19, and thus is allowable for at least the same reasons as 
for claim 19. Furthermore, claim 29 recites that the controller is adapted to further send 
messaging to perform a reverse log-on procedure with the destination terminal. Claim 29 is 
allowable over the asserted combination of DeSimone, Auerbach, and Ishikawa for reasons 
similar to those as claim 7. 

In view of the foregoing, it is respectfully requested that the final rejection of claims 7 
and 29 be reversed. 
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D. Are Claims 34, 36, 38, 40, And 42 Obvious Over The Asserted Combination Of 
DeSimone, Auerbach, And Busey? 

Claim 34, which depends from claim 1, is allowable for at least the same reasons as claim 
1. Furthermore, claim 34 recites providing a response, from the second community server, to the 
first terminal to present a web page in a web browser on a first terminal, and receiving a text 
message of the real-time, text-based messaging session originated from the web browser on the 
first terminal. The Examiner pointed to column 1, lines 55-67, of DeSimone as teaching 
providing a response, from a second community server, to the first terminal to present a window 
in a graphical user interface. As already conceded by the Examiner, DeSimone does not teach 
multiple servers associated with multiple service providers. The response to present a web page 
as recited in claim 34 is provided by a second community server associated with a second service 
provider. Thus, DeSimone clearly does not disclose providing a response from a second 
community server associated with a second service provider to a first terminal to present any 
form of graphical user interface, much less a web page. Although Busey teaches use of a web 
browser to establish chat sessions, Busey is also a one-service provider system (multiple chat 
clients establish TCP/IP connections to a host computer). Busey, 3:24-29. Thus, Busey also 
fails to teach or suggest providing a response from a second community server associated with a 
second service provider to a first terminal (coupled to a server of the first service provider) to 
present a web page on the first terminal. 

Therefore, claim 34 is not obvious over the asserted combination of DeSimone, 
Auerbach, and Busey. 

Claim 36 is similarly allowable. Claim 36 depends from claim 19, and is thus allowable 
for at least the same reasons as for claim 19. Moreover, claim 36 recites that a controller 
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(associated with a first community that is associated with one service provider) is able to 
communicate a web page for display on an entity associated with another community associated 
with a different service provider. As discussed above, neither DeSimone nor Busey teaches or 
suggests this subject matter. 

Claim 38, which also depends from claim 19, is allowable for similar reasons. 

Also, claim 40, which depends indirectly from claim 20, is allowable for at least the same 
reasons as claim 20. Moreover, claim 40 recites that instructions when executed cause a system 
(in a first community associated with a first service provider) to provide a web page for display 
at a subscriber terminal in a second community associated with a second service provider. Such 
a feature is not disclosed by either DeSimone or Busey, contrary to the assertion made by the 

Examiner. Therefore,daim 40 is allowable over the asserted combination of DeSimone, 

Auerbach, and Busey. 

Claim 42, which depends from claim 20, is similarly allowable. 

In view of the foregoing, it is respectfully requested that the final rejection of claims 34, 
36, 38, 40, and 42 be reversed. 



Applicant respectfully requests that each of the final rejections be reversed and that the 
claims subject to this appeal be allowed to issue. 

Respectfully submitted, 



IX. 



CONCLUSION 





Dan C. Hu, Reg. No. 40,025 
TROP, PRUNER & HU, P.C 



8554 Katy Fwy, Ste 100 
Houston, TX 77024-1805 
713/468-8880 [Phone] 



713/468-8883 [Facsimile] 
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CLAIMS ON APPEAL 



1 LA method of communicating in a network having a plurality of 

2 communities each including a server, the method comprising: 

3 receiving, from the server in a first community associated with a first 

4 service provider, a request indicating desired real-time, text-based messaging from a first 

5 terminal coupled to the first community server to a second terminal coupled to the server 

6 in a second community associated with a second, different service provider; and 

7 processing the request, by the server in the second community, to establish 

8 a real-time, text-based messaging session between the first and second terminals through 

9 the- first and second community servers. 

1 2. The method of claim 1, further comprising determining if the second 

2 terminal has an established link with the second community server. 

1 3. The method of claim 2, further comprising sending a notification to the 

2 second terminal of the desired messaging session if the second terminal has an 

3 established link with the second community server, 

1 4. The method of claim 3, further comprising receiving an indication from 

2 the second terminal of whether the desired messaging session has been accepted. 

1 5. The method of claim 2, further comprising sending a message to a 

2 predetermined communications device other than the second terminal if the second 

3 terminal does riot have an established connection with the second community server. 

1 6. The method of claim 5, wherein sending the messages includes sending to 

2 a communications device including at least one of a telephone, a pager, and an electronic 

3 mail receiver. 



1 




1 7. The method of claim 2, further comprising performing a reverse log on to 

2 the second terminal if the second terminal does not have an established link with the 

3 second community server. 

1 8. The method of claim 1 , further comprising establishing a chat session 

2 between the first and second terminals. 

1 19. A server for use in a communications system having a plurality of 

2 communities coupled by a network, each community associated with a different service 

3 provider, the server being associated with a first one of the communities and comprising: 

4 an interface unit adapted to receive a contact request over the network 

5 from an entity associated with another community, the entity not logged on to the server, 
6 the contact request indicating a request to establish a text-based messaging session with a 

7 destination terminal linked to the server; and 

8 a controller adapted to send a notification to the destination terminal of the 

9 contact request and to receive an indication from the destination terminal of acceptance 
1 0 of the contact request. 

1 20. An article including one or more machine-readable storage media 

2 containing instructions for establishing a text-based messaging session between 

3 subscribers in a plurality of communities, each community associated with a different 

4 service provider, the instructions when executed causing a system in a first community 

5 associated with a first service provider to: 

6 receive a request from a subscriber in a second community associated with 

7 a second service provider, the request indicating a desired text-based messaging session 

8 with a subscriber in the first community; 

9 notify the subscriber in the first community of the request; 

10 determine if the subscriber in the first community has accepted the 

1 1 request; and 
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12 establish the text-based messaging session between the subscribers if the 

13 subscriber in the first community accepted. 

1 21. The article of claim 20, wherein the one or more storage media contain 

2 instructions that when executed cause the system to further send signaling to establish the 

3 text-based messaging session. 

1 22. The article of claim 20, wherein the text-based messaging session includes 

2 a chat session. 

1 23. The article of claim 20, wherein the one or more storage media contain 

2 instructions that when executed cause the system to create a controller object adapted to 

3 control the text-based messaging session. 

1 24. The article of claim 20, wherein the one or more storage media contain 

2 instructions that when executed cause the system to: 

3 receive a request from a subscriber in a third community associated with a 

4 third service provider for a text-based messaging session; and 

5 establish the text-based messaging session among the subscribers in the 

6 first, second, and third communities. 

1 27. The method of claim 1, wherein receiving the request comprises receiving 

2 a request indicating a desired interactive, text-based chat session. 

1 28. The server of claim 19, wherein the text-based messaging session 

2 comprises an interactive, text-based chat session. 

1 29. The server of claim 19, wherein the controller is adapted to further send 

2 messaging to perform a reverse log-on procedure with the destination terminal. 
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1 30. The article of claim 20, wherein the instructions when executed cause the 

2 system to establish the text-based messaging session by establishing an interactive, text- 

3 based chat session. 

1 32. The method of claim 1 , further comprising providing a web page for 

2 display at the first terminal, wherein receiving the request comprises receiving a message 

3 generated in response to a selection made in the web page. 

1 33. The method of claim 1 , further comprising: 

2 providing a session object in the second community server, 

3 wherein receiving the request comprises receiving a request at the session 

4 object in the second community server from another session object in the first community 

5 server; and 

- 6 the session object in the second community server exchanging messaging 

7 with the first community server to establish the real-time, text-based messaging session. 

1 34. The method of claim 1 , further comprising: 

2 providing a response, from the second community server, to the first 

3 terminal to present a web page in a web browser on the first terminal; and 

4 receiving a text message of the real-time, text-based messaging session 

5 originated from the web browser on the first terminal. 

1 35. The server of claim 19, wherein the interface unit is adapted to receive the 

2 contact request from a second server in the other community. 

1 36. The server of claim 19, wherein the controller is adapted to communicate 

2 a web page for display on the entity, 

3 the contact request comprising a message generated in response to user 

4 selection made in the web page at the entity. 
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1 37. The server of claim 19, wherein the controller comprises a session object, 

2 the session object adapted to exchange messaging with another session 

3 object in a second server in the other community to establish the text-based messaging 

4 session. 

1 38. The server of claim 19, wherein the controller is adapted to communicate 

2 a response to the contact request to present a web page in a web browser at the entity, 

3 the interface unit adapted to further receive text messaging from the web 

4 browser at the entity during the text-based message session. 

1 39. The article of claim 20, wherein the instructions when executed cause the 

2 system to receive the request at a first server in the system from a second server in the 

3 second community. 

1 40. The article of claim 39, wherein the instructions when executed cause the 

2 system to provide a web page for display at a subscriber terminal in the second 

3 community, 

4 wherein the request received at the first server comprises messaging 

5 generated in response to selection made in the web page displayed at the subscriber 

6 terminal in the second community. 

1 41 . The article of claim 39, wherein the instructions when executed cause the 

2 system to: 

3 provide a session object in the system; and 

4 cause the session object to exchange messaging with the second server to 

5 establish the text-based messaging session. 

1 42. The article of claim 20, wherein the instructions when executed cause the 

2 system to: 

3 communicate, in response to the request, a web page for display in a web 

4 browser at a subscriber terminal in the second community; and 
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5 receive messaging from the web browser during the text-based messaging 

6 session. 
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